1. Field of Invention
The present invention relates to methods for operating a plurality of computers in a similar manner to the way in which a shell or command interpreter operates a single machine.
2. Prior Art
Hereinafter the term shell will be used to refer to a shell or command interpreter. Examples of shells in the prior art include command.com supplied with Microsoft DOS, bash used on Unix and Linux systems and explorer.exe, the graphical user interface supplied with Microsoft Windows XP.
Shells and Other Software
A general purpose computer system runs several pieces of software which can be viewed as providing different levels of functionality. This is illustrated in FIG. 1. Here the level of functionality is determined by how abstract a task is compared to the actual functions of the computer hardware. It does not necessarily relate to the complexity of the software.
The operating system, including device drivers (101), is the lowest level software component. The operating system is concerned with for example opening and closing files, launching and managing applications and interfacing with the hardware (102). The operating system provides an application programming interface for higher level software components (103). The functions in this interface are known as system calls. FIG. 1 shows how higher level software builds (104) on lower level software to perform functions which are both more abstract and more directly useful to the user.
Because the operating system is accessed with system calls it cannot be used directly by a user. A shell (105) is an application which provides a user interface to the basic functionality supported by the operating system. As its functions are fairly close to those provided by the operating system it is considered to be a low level application.
A shell can be text based, like for example “bash” or “csh”, or provide a graphical user interface like explorer.exe which displays files and folders under Windows XP. Shells may be closely associated with particular operating systems but they are application programs.
Shells are usually designed to work on a particular operating system but in some cases they can be adapted to work on a variety of operating systems. For example, the bash shell, originally designed to work on unix-like operating systems can be used under Microsoft Windows XP.
Some shells provide additional functionality not directly supported by the underlying operating system. For example bash provides commands for storing and retrieving variables, commands for conditionally executing other commands and commands for executing commands several times.
Some shells can accept a sequence of commands from a file. This capability, together with the additional commands mentioned above mean the shell can also act as an interpreter for a simple programming language. A program written for a shell is known as a shell script or batch file (106).
Terminals and Terminal Emulators
Historically interaction with a central computer was done via a terminal. This is illustrated in FIG. 2. This diagram illustrates a physical terminal (201), for example a VT320 made by Digital, being used with a unix-like operating system. The terminal is connected to a port on the computer (202) and this port is managed by part of the operating system called the terminal driver (203). This terminal driver provides a standardised interface to the physical terminal (204) which an application program (205) can interact with. One such application program would be a shell.
FIG. 3 illustrates a modern computing environment where physical terminals are usually replaced with terminal emulation programs (301, 302) running on desktop computers (303) or on the central computer itself (304). The terminal emulation software sends and receives characters and displays characters to the user in the same way a physical terminal would do. In order to allow application programs to use this emulated terminal in the same way as they would use a real terminal an operating system component known as a pseudo terminal (305) is used. The pseudo terminal provides a terminal interface to the application program (306) in the same way the terminal driver would do if a physical terminal were used. The pseudo terminal then presents a second interface to the terminal emulation program to allow it to send characters to and receive characters from the operating system in the same way a physical terminal would send characters to and receive characters from the computer hardware and terminal driver.
Running Process on Remote Systems
Several technologies are available for running a program on a remote computer from a local computer. One example under Unix and unix-like operating systems is “rsh”. This allows users to either start an interactive shell on a remote machine or to launch a process on a remote machine making the results available on the first machine. The use of rsh can be seen in FIG. 3. The system consists of a daemon process (307) and a client component (308).
Other techniques used at a programming level to access remote systems include Remote Procedure Calls (RPC), Remote Method Invocation (RMI), etc.
Shared File Systems
Several technologies are available to make files from one computer available to other computers on a network. One such example is Network File System (NFS) originally developed by Sun Microsystems, widely used on Unix and unix-like operating systems. Another example is the Common Internet File System (CIFS), widely used by Microsoft.
User Accounts
Modern operating systems maintain separate accounts for different users. Accounts are also used for different functions, for example a system account may be used for running processes related to the operating system. Different accounts may have different access privileges. Users may sometimes need to access multiple accounts on the same system or need to use different account credentials on different systems for a variety of reasons.
Limitations of Current Shells
Current shell software is designed to perform operations on the machine on which it is running. Commands which deal with multiple machines are not supported directly by current shells. There are two main aspects to accessing remote machines: access to files and the ability to run processes.
Files on remote machines can be accessed using shared file systems as described above. However, files on a remote machine are not typically available in the same way on a remote machine as they are on a local machine. When accessing files remotely it may be that only a subset of the files are available and access rights may be different to those obtained when working on the machine directly. Furthermore, the paths used for a particular file may be different from machine to machine. Also note that such remote file access is a function of the underlying operating system and not a function of the shell itself.
Current shells do not directly launch processes on remote machines. Instead remote processes are typically started by a separate program designed for this purpose which is, as far as the shell is concerned, just another local command. For example, when using the bash shell on a Unix system a user may use the rsh command to start a process on another machine. The rsh command is not part of the bash shell and running a remote command like this is not as easy as running a command locally. When entering the name or arguments of the command to run on the remote machine for example, command line completion is not available as it would be for a local command. The shell cannot provide facilities like command line completion because it is not directly operating on the remote machine.
The problems of remote file access and remote process execution compound one another because any view of the remote file system available to the user is likely to be different from the file system view which will be available to the remote process. Users must understand and remember the relationship between the two sets of file systems when entering commands which involve a remote machine and files which can be seen from both machines.
Shells are also limited in the way they can handle multiple user accounts. Although the operating system may allow some flexibility in mapping account names on remote file systems, shells themselves are currently designed to work directly with only one set of user credentials. As with remote process execution, separate programs can be used to launch processes with different account credentials but this method is difficult to use. Under Unix for example the “su” command can be used to launch a program using a different user account. Again the shell will not be fully aware of the environment under which the new command will be launched and may not be able to provide correct completions for the command and arguments etc.
Another problem with both running processes on remote machines and running processes under different accounts on the same machine is that launching processes this way may require passwords. These passwords may be required each time the command is executed and the password prompting process may interfere with the intended operation of the overall command.
Yet another problem with current shells which use a text based user interface is that they do not cope well with running multiple commands simultaneously. For example, using the bash shell, commands can be put into the background allowing other commands to be launched.
This has several problems:    (1) The output from multiple background processes is mixed on the screen.    (2) Output from background tasks gets mixed with the user input required to launch further tasks making commands being entered unreadable.    (3) Background tasks are stopped when they attempt to obtain input from the user. Users must enter further commands to switch between processes. Also a process designed to perform processing whilst simultaneously being responsive to user input may not perform correctly as all processing is likely to be stopped once user input is requested.    (4) Commands which have been launched with different user credentials (using an auxiliary command to alter these as described above) may not be able to interact correctly with the terminal because of the ownership and access permissions associated with the terminal, pseudo terminal or equivalent.